home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-atm-mtu-03.txt < prev    next >
Text File  |  1993-10-29  |  13KB  |  335 lines
  1.  
  2. Network Working Group                                Randall J. Atkinson
  3. Request for Comments: DRAFT                    Naval Research Laboratory
  4. <draft-ietf-atm-mtu-03.txt>                              29 October 1993
  5.  
  6.                   Default IP MTU for use over ATM AAL5
  7.  
  8. Status of this Memo
  9.  
  10.      Internet Drafts are working documents of the Internet Engineering
  11.    Task Force (IETF), its Areas, and its Working Groups.  Note that
  12.    other groups may also distribute working documents as Internet
  13.    Drafts.  This particular draft is a working document of the IETF's
  14.    "IP over ATM" working group.  It is intended to eventually submit
  15.    this draft to the IESG for possible release as a standards-track RFC.
  16.  
  17.      Internet Drafts are draft documents valid for a maximum of six
  18.    months.  This Internet Draft expires on 29 April 1994.  Internet
  19.    Drafts may be updated, replaced, or obsoleted by other documents at
  20.    any time.  It is not appropriate to use Internet Drafts as reference
  21.    material or to cite them other than as a "working draft" or "work in
  22.    progress".
  23.  
  24.      Please check the I-D abstract listing contained in each Internet
  25.    Draft directory to learn the current status of this or any other
  26.    Internet Draft.
  27.  
  28.      Distribution of this memo is unlimited.
  29.  
  30. Default Value for IP MTU over ATM AAL5
  31.  
  32.      Protocols in wide use throughout the Internet, such as the Network
  33.    File System (NFS), currently use large frame sizes.  Empirical
  34.    evidence with various applications over the Transmission Control
  35.    Protocol (TCP) indicates that larger Maximum Transmission Unit (MTU)
  36.    sizes for the Internet Protocol (IP) tend to give better performance.
  37.    Fragmentation of IP datagrams is known to be highly undesirable.
  38.    [KM87] It is desirable to reduce fragmentation in the network and
  39.    thereby enhance performance by having the IP Maximum Transmission
  40.    Unit (MTU) for AAL5 be reasonably large.  NFS defaults to an 8192
  41.    byte frame size.  Allowing for RPC/XDR, UDP, IP, and LLC headers, NFS
  42.    would prefer a default MTU of at least 8300 octets.  Routers can
  43.    sometimes perform better with larger packet sizes because most of the
  44.    performance costs in routers relate to "packets handled" rather than
  45.    "bytes transferred".  So there are a number of good reasons to have a
  46.    reasonably large default MTU value for IP over ATM AAL5.
  47.  
  48.      RFC 1209 specifies the IP MTU over SMDS to be 9180 octets, which is
  49.    larger than 8300 octets but still in the same range. [RFC-1209] There
  50.  
  51.  
  52.  
  53. Atkinson                                                        [Page 1]
  54.  
  55. Internet Draft                                           29 October 1993
  56.  
  57.  
  58.    is no good reason for the default MTU of IP over ATM AAL5 to be
  59.    different from IP over SMDS, given that they will be the same
  60.    magnitude.  Having the two be the same size will be helpful in
  61.    interoperability and will also help reduce incidence of IP
  62.    fragmentation.
  63.  
  64.      Therefore, the default MTU for IP over ATM AAL5 shall be 9180
  65.    octets.  All implementations compliant and conformant with this
  66.    specification shall support this default IP MTU value for use over
  67.    ATM AAL5.
  68.  
  69.  
  70.  
  71. Minimum Value for IP MTU over ATM AAL5
  72.  
  73.      The smallest acceptable value for the IP MTU for use over ATM AAL5
  74.    is 576 octets.  This value conforms with the requirements of the Host
  75.    Requirements RFC and is consistent with the IP specification.  [RFC-
  76.    793, RFC-1122]. All ATM Forum compliant implementations of ATM
  77.    technology are capable of handling this restriction without
  78.    difficulty.  This restriction is placed in order to minimise the
  79.    occurence for IP fragmentation, which is known to be harmful, and to
  80.    ensure support for future versions of IP that are currently in
  81.    development.  Note that this minimum MTU does not place any lower
  82.    bound on the size of the IP datagram that may be transmitted by any
  83.    system.  Rather, it ensures that all systems will handle IP datagrams
  84.    of size less than or equal to 576 octets without IP fragmentation.
  85.    Before such a small MTU value may be used, the requirements described
  86.    in the MTU NEGOTIATION section must be adhered to.
  87.  
  88.  
  89.  
  90. MTU Negotation for ATM AAL5
  91.  
  92.      The ATM signalling protocol uses two different parts of the
  93.    Information Element named "AAL Parameters" to exchange information on
  94.    the MTU over the ATM circuit being setup [ATMF93a].  The component
  95.    named "Forward Maximum CPCS-SDU Size Identifier" contains the value
  96.    over the path from the calling party to the called party.  The
  97.    component named "Backwards Maximum CPCS-SDU Size Identifier" contains
  98.    the value over the path from the called party to the calling party.
  99.    The ATM Forum specifies the valid values of this identifier as 1 to
  100.    65534 inclusive.  Not all of those values make sense in the context
  101.    of IP over ATM as is explained in the preceding section, so not all
  102.    of those values may be used by implementations of this specification.
  103.    Note that the ATM Forum's User-to-Network-Interface (UNI) signalling
  104.    permits the MTU in one direction to be different from the MTU in the
  105.    opposite direction, so the ATM information elements might have
  106.  
  107.  
  108.  
  109. Atkinson                                                        [Page 2]
  110.  
  111. Internet Draft                                           29 October 1993
  112.  
  113.  
  114.    different values on the same connection.
  115.  
  116.      Other MTU values for ATM AAL5 (i.e. other than the default value
  117.    specified above) shall not be used unless use of the other MTU value
  118.    was successfully negotiated using industry-standard ATM-specific
  119.    mechanisms (e.g. ATM Signalling Protocol) prior to being attempted.
  120.    If negotiation of the MTU value is attempted but fails, then the
  121.    default MTU value shall be used.  If either of the above cited
  122.    information elements is not present in the ATM Signalling Protocol's
  123.    "SETUP" message, then the default MTU value shall be used for each
  124.    missing value.  If the calling device erroneously sets the value of
  125.    either information element to 0, then either the default MTU value
  126.    shall be used or the party receiving the invalid value shall clear
  127.    the call with cause "Invalid Information Element Contents" being
  128.    indicated.
  129.  
  130.      If the calling party wishes to use the default MTU but is willing
  131.    and able to negotiate an MTU size other than the default, it should
  132.    include the "AAL Parameters" information element with the default
  133.    values for the Maximum CPCS-SDU Size Identifier as part of the SETUP
  134.    message of the ATM signalling protocol [ATMF93b].  If the calling
  135.    party desires to use a different value than the default, it must
  136.    include the "AAL Parameters" information element with the desired
  137.    value for the Maximum CPCS-SDU Size Identifier as part of the SETUP
  138.    message of the ATM Signalling Protocol.  The value of these
  139.    identifiers may range from 576 to 65535 octets in an implementation
  140.    of this specification.  If the calling party is only willing to use
  141.    the default MTU value, the Maximum CPCS-SDU components must not be
  142.    specified in the SETUP message.  The called party will respond using
  143.    the same information elements and identifiers in its CONNECT message
  144.    response [ATMF93c].
  145.  
  146.      If the called party receives a SETUP message containing a "Maximum
  147.    CPCS-SDU Size Identifier" in the "AAL Parameters" information
  148.    element, it shall handle the Maximum CPCS-SDU Size Identifier as
  149.    follows:
  150.  
  151.  
  152.        a) If it is able to accept the proposed MTU values, it shall set
  153.        the values of the Maximum CPCS-SDU Size Identifier equal to the
  154.        proposed values and include that information in its CONNECT
  155.        message responding to the original SETUP message.
  156.  
  157.        b) If it wishes a smaller MTU size than that proposed but greater
  158.        than or equal to 576, then it shall set the values of the Maximum
  159.        CPCS-SDU Size Identifier equal to the desired value in its
  160.        CONNECT message responding to the original SETUP message.
  161.  
  162.  
  163.  
  164.  
  165. Atkinson                                                        [Page 3]
  166.  
  167. Internet Draft                                           29 October 1993
  168.  
  169.  
  170.        c) If it does not wish to negotiate the MTU, it shall not include
  171.        the Maximum CPCS-SDU Size Identifiers in its CONNECT message
  172.        responding to the original SETUP message.
  173.  
  174.  
  175.      If a called endpoint receives a SETUP message containing no
  176.    "Maximum CPCS-SDU Size Identifier" in the "AAL Parameters"
  177.    information element, it shall not include such an identifier in the
  178.    CONNECT message sent in response to the original SETUP message and
  179.    the default IP MTU for use over AAL5 shall be used by both parties.
  180.  
  181.      If the called endpoint incorrectly includes the "Maximum CPCS-SDU
  182.    Size Identifier" in the CONNECT messages (e.g. because the original
  183.    SETUP message did not include such information) or it sets such an
  184.    identifier to a value less than 576 or more than the value of the
  185.    original SETUP message, then the calling party shall clear the call
  186.    with cause "Invalid Information Element Contents" being indicated.
  187.  
  188.  
  189.  
  190. Path MTU Discovery Required
  191.  
  192.      The Path MTU Discovery mechanism is an Internet Standard and is an
  193.    important mechanism for reducing IP fragmentation in the Internet.
  194.    This mechanism is particularly important because new subnet
  195.    technologies, such as ATM, use default MTU sizes different from older
  196.    subnet technologies such as Ethernet and FDDI.
  197.  
  198.      In order to ensure good performance throughout the Internet and
  199.    also to permit IP to take full advantage of the potentially larger IP
  200.    datagram sizes supported by ATM, all implementations that comply or
  201.    conform with this specification must also implement the IP Path MTU
  202.    Discovery mechanism as defined in RFC-1191 and clarified by RFC-1435.
  203.  
  204.  
  205.  
  206. Security Considerations
  207.  
  208.    Security Considerations are not discussed in this memo.
  209.  
  210.  
  211.  
  212. References
  213.  
  214.    [RFC-791] J. Postel, Internet Protocol, RFC-791, DDN Network
  215.    Information Center, September 1981.
  216.  
  217.    [RFC-793] J. Postel, Transmission Control Protocol, RFC-793, DDN
  218.  
  219.  
  220.  
  221. Atkinson                                                        [Page 4]
  222.  
  223. Internet Draft                                           29 October 1993
  224.  
  225.  
  226.    Network Information Center, September 1981.
  227.  
  228.    [RFC-1122] R. Braden (Ed.), Requirements for Internet Hosts --
  229.    Communications Layers, RFC-1122, DDN Network Information Center,
  230.    October 1989, pp.58-60.
  231.  
  232.    [RFC-1191] J. Mogul & S. Deering, Path MTU Discovery, RFC-1191, DDN
  233.    Network Information Center, November 1990.
  234.  
  235.    [RFC-1209] D. Piscitello, D & J. Lawrence, The Transmission of IP
  236.    Datagrams over the SMDS Service, RFC-1209, DDN Network Information
  237.    Center, March 1991.
  238.  
  239.    [RFC-1435] S. Knowles, IESG Advice from Experience with Path MTU
  240.    Discovery, RFC-1435, DDN Network Information Center, March 1993.
  241.  
  242.    [ATMF93a] R. Breault, J. Grace, J. Jaeger, & L. Wojnaroski(eds.), ATM
  243.    Forum User Network Interface Specification, Version 2.4 (clean),
  244.    Document 93-620R3, Section 5.4.5.5, p. 174, 5 August 1993, ATM Forum.
  245.  
  246.    [ATMF93b] R. Breault, J. Grace, J. Jaeger, & L. Wojnaroski(eds.), ATM
  247.    Forum User Network Interface Specification, Version 2.4 (clean),
  248.    Document 93-620R3, Section 5.3.1.7, p. 149-150, 5 August 1993, ATM Forum.
  249.  
  250.    [ATMF93c] R. Breault, J. Grace, J. Jaeger, & L. Wojnaroski(eds.), ATM
  251.    Forum User Network Interface Specification, Version 2.4 (clean),
  252.    Document 93-620R3, Section 5.3.1.3, p. 146, 5 August 1993, ATM Forum.
  253.  
  254.    [KM87] C. Kent & J.Mogul, "Fragmentation Considered Harmful", Proceedings
  255.    of the ACM SIGCOMM '87 Workshop on Frontiers in Computer Communications
  256.    Technology, August 1987.
  257.  
  258.  
  259.  
  260. Acknowledgements
  261.      While all members of the IETF's IP over ATM Working Group have been
  262.    helpful, Vern Schryver, Rob Warnock, Craig Partridge, and Subbu
  263.    Subramaniam have been especially helpful to the author in analysing
  264.    the host and routing implications of the default IP MTU value.
  265.    Similarly, Dan Grossman provided significant help in clarifying the
  266.    optional ATM signalling procedure used to negotiate the IP MTU value.
  267.  
  268. Disclaimer
  269.  
  270.      Author's organisation provided for identification purposes only.
  271.    This document presents the author's views and is not necessarily the
  272.    official opinion of his employer.
  273.  
  274.  
  275.  
  276.  
  277. Atkinson                                                        [Page 5]
  278.  
  279. Internet Draft                                           29 October 1993
  280.  
  281.  
  282. Author Information
  283.  
  284.    Randall J. Atkinson     <atkinson@itd.nrl.navy.mil>
  285.  
  286.    Information Technology Division
  287.    Naval Research Laboratory
  288.    Washington, DC 20375-5320
  289.    USA
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. Atkinson                                                        [Page 6]
  334.  
  335.